Update license field to Python-2.0.1 - #188

Maybe worth changing to PSF-2.0 (with license text) then?

There is a long story of issues about the license. I just wish for proper attribution "from upstream" and for this question to be solved once and for all. Without diving into details.

The only difference, PSF-2.0 & Python 2.0.1 have no flag "OSI approved". I don't know how critical that is.

Can you give a qualified answer about attribution for this package? Or maybe you know someone who can help? I'm not a lawyer :)

Assuming that the LICENSE file in the latest release is the correct one, the most appropriate SPDX license should be Ptyhon-2.0.1 because it includes:

• PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2
• BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0
• CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1
• CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2

Instead, if you also want to change the LICENSE file, I don't know what the best one is. For sure the PSF-2.0 is the simpler one. I don't know of any downside to not being OSI approved.

From my point of view as Fedora packager both the PSF-2.0 and Python-2.0.1 are fine, they are both allowed in Fedora:
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

I'm neither a lawyer nor an expert on licenses.

Don't consider LICENSE a requirement; it's part of attribution and can be modified at your discretion. As far as I understand:

• Python-2.0
  • Not suitable, because not GPL-compatible.
  • Has a very confusing LICENSE.
• Possible choices are:
  • PSF-2.0
  • Python-2.0.1 (GPL-compatible, but still confusing LICENSE).
  • Both alternatives have no OSI-approved flag in SPDX (that's a fact, not a reason to decline).

Additional context:

• This package is written by @rlidwka and me. We can change the license as we need, without a complicated process.
• Only upstream demands should be satisfied. No extra demands from our side.

I tend to update to PSF-2.0, but need to understand any possible side effects (I hope there are none) - scanner errors and so on.

If you know where to ask for audit - let me know.

To get a qualified opinion, you could try asking to help@softwarefreedom.org, on https://softwarefreedom.org/ is written:

The Software Freedom Law Center provides pro-bono legal services to developers of Free, Libre, and Open Source Software.

Also you could try to asking to licence-questions@fsfe.org on https://fsfe.org/freesoftware/legal/faq.en.html is written:

If your question is not covered here or in any of our other resources, you can consider asking our Licence Questions team by sending them an email at licence-questions@fsfe.org.

Hi, while preparing a new package for Fedora that use argparse as dependency I found that the Python-2.0 is not allowed in Fedora.

Actually, it probably would be, but hasn't been formally reviewed, since it was discovered (when Fedora switched to using SPDX identifiers) that Python-2.0 wasn't actually used in any known release (or at least any known release in the past couple of decades) of CPython.

But apparently the license in this repository is Python-2.0.1, not Python-2.0.

To get a qualified opinion, you could try asking to help@softwarefreedom.org, on https://softwarefreedom.org/ is written:

The Software Freedom Law Center provides pro-bono legal services to developers of Free, Libre, and Open Source Software.

I don't think SFLC (a former employer of mine) is actively providing legal services anymore.

Maybe worth changing to PSF-2.0 (with license text) then?

There is a long story of issues about the license. I just wish for proper attribution "from upstream" and for this question to be solved once and for all. Without diving into details.

The only difference, PSF-2.0 & Python 2.0.1 have no flag "OSI approved". I don't know how critical that is.

Can you give a qualified answer about attribution for this package? Or maybe you know someone who can help? I'm not a lawyer :)

I think the issue here is that if this is a port of Python argparse, it may be covered in part by the relevant CPython license. On the Fedora legal list @puzrin says:

argparse was added to CPython in 2010 under the PSF Contributor Agreement, so none of
the ported code comes from the CWI, CNRI or BeOpen eras.

Can the port be licensed as PSF-2.0 alone, or does CPython-derived code have to carry
the whole stack?

If indeed none of the ported code comes from the CWI/CNRI/BeOpen areas there wouldn't seem to be any basis for anyone to insist on PSF-2.0 not being an adequate license by itself.

@richardfontana

But apparently the license in this repository is Python-2.0.1, not Python-2.0.

No, we really attributed it as Python-2.0 from SPDX because it's the only one with the OSI-approved flag in SPDX. Also, Python-2.0.1 may not have existed in the SPDX database at the time.

Probably, this was a mistake - I'm not an expert in this area. I'd like to solve a practical issue:

• Finally, stop the issues in the tracker :) Because of the cryptic Python-2.0 license text.
• Avoid alerts in license scanners about incompatible licenses (don't know if the OSI-approved flag is significant or if existing in SPDX is enough).

From my unqualified point of view, PSF-2.0 is the clearest, in case we should adjust Python-2.0 to something else. But I don't know if it's correct to use it.

Seems like PSF-2.0 would be okay based on what I'm reading here. If I remember correctly, the PSF had intended to submit PSF-2.0 (i.e. standalone from the license that was submitted as Python-2.0 though that should have had the text of what later came to be labeled Python-2.0.1) for OSI approval but for some process related reason that never happened. The fact that PSF-2.0 by itself is not OSI-approved might matter to some but I wouldn't expect most people to care - if only because PSF-2.0 clearly contains no OSI-approval problem since it was approved as part of the stack of licenses in the (mistaken) Python-2.0 submission.